Repository navigation
Fix a dropped morpheme ID when a zero-width rule wraps one ending at the same node - #500
johnml1135 wants to merge 1 commit into
Conversation
b15073b to
96d6b7f
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #500 +/- ##
=======================================
Coverage 74.57% 74.57%
=======================================
Files 453 453
Lines 38314 38314
Branches 5280 5280
=======================================
+ Hits 28573 28574 +1
Misses 8576 8576
+ Partials 1165 1164 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
96d6b7f to
5aa7b39
Compare
5aa7b39 to
157c031
Compare
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| // Truncation and zero-width rules have no new morph. Mark the last node after the | ||
| // loop, so a wrapped allomorph ending there keeps it and this rule's ID sorts after. | ||
| string morphID = output.MorphologicalRuleApplicationCount.ToString(); | ||
| output.MarkMorph(new List<ShapeNode>() { output.Shape.Last }, _allomorph, morphID); |
There was a problem hiding this comment.
Minor: F1. The wrapped morph now loses its last segment. MarkMorph re-parents node annotations (AnnotationList.Add calls node.Remove(false)), so marking Shape.Last after the loop moves that node from the wrapped morph to this zero-width rule. For fen + IDENT, the root morph keeps f e and IDENT takes n; for fenos, QTOP keeps no nodes. Before this change, the zero-width morph was the one left empty, which fits a rule that adds no segments. Traced through the code, not run.
| { | ||
| const string CorrectSig = "FEN+PTOQ+QTOP+IDENT|fenos;FEN+PTOQ+QTOP|fenos"; | ||
| bool sawCorrect = false; | ||
| for (int trial = 0; trial < 100 && !sawCorrect; trial++) |
There was a problem hiding this comment.
FYI: F2. This test passes if any one of 100 loads gives the right signature, so it stays green even if the fix works only 1 time in 100. AGENTS.md asks for deterministic fixtures. That is fine as a stopgap if this becomes an every-attempt assertion once #506 is fixed.
|
|
||
| private static string ParseWithFreshMorpher(Language language, string word) | ||
| { | ||
| // maxDegreeOfParallelism: 1 matches ConformanceMorpherFactory.Create's default |
There was a problem hiding this comment.
FYI: F3. These comments point to code that does not exist in this repo: ConformanceMorpherFactory.Create and useMemoization here (the memo was removed in #522), and BatchCommand.BuildSignature at line 110. A grep over src and tests finds none of the three.
| [Test] | ||
| public void Fenos_IdentityWrapsOutermost_IsFlakyPendingASeparateOrderingDefect() | ||
| { | ||
| // Measured: fix reaches the correct signature 41/100 fresh loads; reverted, 0/100. The |
There was a problem hiding this comment.
FYI: F4. Measured: ... 41/100 ...; reverted, 0/100 records history and will go stale after the next change. .claude/skills/code-comments/SKILL.md rules out history in comments, and the PR body already has these numbers.
Public API, target frameworks, packages, and Findings: F1 new, unverified (traced, not run); F2 new; F3 new; F4 new. Reviewed at 157c031 |
Pin full parse multiplicity and application histories from combined Machine #500 and #556 in three derivatives of the #480 truncation grammar. Update fixture-derived coverage, interaction ledgers and their audit pins. The original grammar is unchanged. The complete expectations intentionally remain red on the conformance branch until both engine fixes are applied.
157c031 to
857313b
Compare
Pin full parse multiplicity and application histories from combined Machine #500 and #556 in three derivatives of the #480 truncation grammar. Update fixture-derived coverage, interaction ledgers and their audit pins. The original grammar is unchanged. The complete expectations intentionally remain red on the conformance branch until both engine fixes are applied.
…the same node In SynthesisAffixProcessAllomorphRuleSpec.ApplyRhs, a zero-width rule's fallback "no new output morphs" marking claimed the shared final shape node before the loop that re-marks the wrapped rule's own morph, so the wrapped rule's morpheme ID could be overwritten or ordered ahead of the outer rule's. Move the fallback marking after that loop so the wrapped allomorph keeps its ID and the outer rule's ID sorts after it. Adds IdentityRuleSignatureMorphDropTests with two deterministic controls and one regression that retries fresh language loads. Measured over 100 fresh loads: with the fix, the correct signature is reached 41/100 times; with the fix reverted, 0/100 -- confirmed by reverting the production change and rerunning. The remaining gap under the fix is a separate, unfixed ordering defect (tracked in #506); this PR does not make output deterministic for every ordering, only reachable. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
857313b to
b86120f
Compare
579b2ef to
41f319f
Compare
Start here:
src/SIL.Machine.Morphology.HermitCrab/MorphologicalRules/SynthesisAffixProcessAllomorphRuleSpec.cs,ApplyRhs: one block of code moved below a loop.Status: stacked on #556 — merge in order #556 → #500 → #480 → #578.
Status: open since 2026-09-14. An automated review (
claude) asks for changes: marking the last shape node after the loop moves that node from the wrapped morph to the zero-width rule, so the wrapped morph loses its last segment (F1); thefenostest passes if any one of 100 loads is right (F2); and test comments point at code absent from this repo (F3, F4). No CI check is red (claude-reviewwas skipped;code-review/reviewableis pending).When a zero-width rule (such as a copy-only
CopyFromInput) wraps another rule's affix and both mark the same trailing shape node, the wrapped morpheme ID was dropped.ApplyRhsnow marks the zero-width rule's last node after the loop that re-marks wrapped input morphs, so the wrapped ID sticks and the outer rule's ID sorts after it.Reviewers arrive asking whether the regression test is deterministic. It is not: the fix makes the correct signature reachable in 41 of 100 fresh language loads in an earlier measurement, and 0 of 100 with the fix reverted. The rest trace to a separate, unfixed ordering defect (#506, open; #556 addresses its tie-boundary mechanism and is open). The question worth your time is F1: does the node move cost the wrapped morph its last segment in a case the tests do not cover?
Where to look:
ApplyRhs: theoutputNewMorph == nullmarking now runs after the loop. Pinned only by the tests below.IdentityRuleSignatureMorphDropTests: controlsFen_BareRootControl_IdentityWrapsRootDirectly_StableAndCorrectandFeno_NoIdentityRuleApplies_StableAndCorrectare deterministic.Fenos_IdentityWrapsOutermost_IsFlakyPendingASeparateOrderingDefectretries up to 100 fresh loads and passes on the first correct signature.Not here: the ordering defect behind #506, which keeps the regression from passing on every attempt.
Verification: build, the HermitCrab tests,
csharpierand the comment-hygiene script passed when the PR was opened; counts are not recomputed here and nothing was rerun for this description.Next: author to answer F1 (with a test, or a reason the lost segment is harmless), then re-request review.
Reading this a year from now -- start here
ApplyRhsmarks morphs on the output shape in two places: a fallback for rules with no new output morphs (truncation and zero-width rules), and a loop that re-marks each input morph the rule wraps. When a zero-width rule's own affix and an inner wrapped rule's affix end at the same trailing shape node, whichever call runs second keeps that node's morpheme ID. The fallback used to run first, so the outer rule's ID could overwrite or precede the wrapped rule's. Moving it after the loop makes the wrapped rule's ID stick and the outer rule's ID sort after it, matching the orderIdentityRuleSignatureMorphDropTestsexpects.Decisions, and why
The
fenostest retries up to 100 fresh loads and passes on the first correct signature. Measured earlier: 41/100 correct with the fix, 0/100 with it reverted. Asserting every attempt would be red even with the fix; a single assertion would be flaky. Retry-until-first-success is the one assertion the data supports, and it goes red with the fix reverted. The cost is that it stays green if the fix works only once in 100 (F2).Paths not taken
An earlier comment blamed
BidirList's unseeded skip-list levels. The source does not support that: same-range annotations tie-break onAnnotation.ListID, a call-order counter. The claim was removed.Deferred
Making every fresh parse deterministic needs the ordering defect in #506 fixed first. Whether #556 is enough is not established; the cause of the per-run variation is not yet identified.
Surprising findings
An earlier revision reported "five green repetitions; suite 575 passed, one skipped, zero failed" and a seed experiment claiming 12/12 repeatability versus three unseeded outputs, attributed to forcing a fixed seed on
BidirList'sRandom. Those numbers were not reproduced and the causal claim did not hold against the source; the 41/100 and 0/100 counts replace them.🤖 Generated with Claude Code
This change is